[レポート]コンプライアンスの観点から見るクラウド設計 – AWS Security Roadshow Japan 2020 #awscloud #AWSSecurityRoadshow

AWS Security Roadshow Japan 2020で行われた「コンプライアンスの観点から見るクラウド設計」のレポートです

#AWS Security Roadshow Japan 2020

臼田佳祐

2020.10.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

本日はAWS Security Roadshow Japan 2020で行われた以下の講演のレポートです。

コンプライアンスセッション「コンプライアンスの観点から見るクラウド設計」

松本照吾

（アマゾンウェブサービスジャパン株式会社セキュリティアシュアランス本部　本部長）

レポート

自己紹介
- AWSの中でセキュリティアシュアランス、規制当局の方とやり取りしている
誰のためのセッション？
- セキュリティはAWSでは最優先事項などと表現している
- Security is everyoneʼs jobとも言っている
  - みんなの責任だよね
- 対象
  - 様々な規制要件に対応することに責任を持つ皆様
    - CxOのような責任者
    - リスク管理部門
    - セキュリティ管理部門など
  - クラウドの技術の進歩に合わせたセキュリティ要件を作り、維持をすることに責任をもつ皆様
    - ポリシーメーカーという役割
    - 従来のものをどう変えていかないといけないのか
    - どうやって維持していくか
  - 様々な要件をAWS上で実現することを求められる皆様
    - エンジニアやアーキテクト
    - 現場のレベルでセキュリティを実現する人
  - 様々な要件の実装や運⽤を評価することを求められる皆様
    - 監査に携わっている方
アジェンダ
- リスクベースアプローチとクラウドコンプライアンス
  - 今様々なセキュリティの基準はリスクベースになっている
- セルフアセスメントによるクラウドコンプライアンス設計
  - AWSが提供するセルフアセスメントのツールを紹介
- “事故前提” – DRにおける想定外への対処
  - 可用性の話

リスクベースアプローチとクラウドコンプライアンス

様々な組織が変更している、あるいは変化したものを適用している段階
クラウドファースト
- 日本ではクラウドバイデフォルトと言っている
- オンプレミスを対象とした規制要件からクラウドを活用した利活用の方針の明確化
  - サービスの利便性を向上するために活用できるのか
  - 何のためにクラウドを使うのですか？という観点で規制要件が変わっている
責任共有による責任範囲の明確化
- オンプレミスでは外部に丸投げしていることがあったかも
- 自分の組織がどのような責任があるのか、事業部はどうか？
- 経営資源をどこに投入すればいいか考える事ができるようになる
- 何のためのガバナンスか
原則中心のアプローチ
- 変化が激しい(IoT/マシンラーニングなど)技術分野の管理
- 何が目的でセキュリティを実現するのか
- 何のためにセキュリティをやるのか？
多くの基準はリスクベースのアプローチ
- ただこれは新しい話ではない
- 日本ではISO27001が多く採用されている
- 組織が管理策を選択している
- 近年だとFISCの安対基準
- 医療は3省3ガイドラインの統合が進んでいる、リスクマネジメントプロセスが重視されている
- 政府がクラウド事業者を評価するISMAPが始まった
  - 全てを網羅しろと言っているわけではない
- 組織のセキュリティ基準もこういった基準を参考にすることが求められている
リスクベースアプローチ: 組織の基礎となるもの
- ISO27001の世界の半分は日本が取得している
- リスクの決定は組織に帰属する
  - リスクマネジメントは組織が経営層の意思決定としてやっている
- リスクの受容水準は組織が決定する
- リスクは有るか無いかではなく高いか低いか
  - 例えばクラウドはリスクが有るのか無いのかではない
- ISMSの中にリスクベースがある
- リスクを取り巻く環境は変わっている
- 新たな技術の採用もリスク管理のアプローチ
- 今日はよりビジネスにITが直結している
- ビジネスを阻害しないスピードで適用していくこと
責任共有モデル
- AWSの考え方、というと少し違う
- 実際はなんでも一緒
- AWSとしての責任範囲が定義されている
- 例えばサッカーでは誰がどこを守るか決まっている
  - 自分たちの行動範囲ややることが明確になれば動きやすい
  - 流動的なゲームのなかでは様々な対応が必要
  - まず責任の範囲があることによって行動を考えることができる
  - サッカーだとオートマティズムという
セキュリティ責任共有モデルはみんなのもの
- AWSが管理するセキュリティ
- パートナーが提供するソリューション、開発、運用の責任
- お客様も責任がある
- 何を守るのか、何を任せるのかを決める
設計による範囲の変化
- 選択したサービスによって責任範囲が違う
- 例えばEC2の上にデータベースを入れる
  - 物理インフラはAWSが面倒を見てくれる
  - OS/ミドルウェアはユーザーが管理する必要がある
  - パッチ適用など
  - サーバーレスなどを利用するとパッチ適用はAWSの責任に
  - ユーザーは自分たちの集中するべきことに集中できる
Well-Architected: 原則中心のアプローチの活用
- セキュリティだけではない様々なベストプラクティス
- 何のために、どういうポイントでやっていくのか
- まず焦点を当てるところを意識する
- その時の技術などと合わせて判断していくことができる

セルフアセスメントによるクラウドコンプライアンス設計

自己評価を自分たちの環境に組み込むための方法
今までのセキュリティの課題
- 予防的な統制が多い
  - 暗号化
  - ネットワークのアクセスコントロール
  - 内部は置いておいて外部からの侵入だけがんばる
- 何かが起きたときにどう対応するかなど、費用対効果の面もあり十分に考慮されてこなかった
- 組織の中のセキュリティが高まっていかないことも
- 現状は攻撃意図や管理作も変わってきている
- 自分たちが持つコントロールは何か？
NIST CSFのホワイトペーパー
- 5つのCore
  - 識別
  - 防御
  - 検知
  - 対応
  - 復旧
- 防御だけでなくそれぞれの観点からセキュリティをバランス良く見直す必要がある
自分たちの今のセキュリティはどうなのか
- Self-Service Security Assessment tool
- AWSのサービスを組み合わせたOSSツール
- Prowler、ScoutSuiteといったOSSのセキュリティ評価ツールをすぐに使える
- 今どうなっているかを可視化できる
- どちらかというと一時点を評価するツール
- ファーストステップとして使うことに有効
- カスタムモジュールとしてランサムウェアに対する脅威の発見もできる
- なんでこれがあるといいのか？
  - 自分たちが判断したりする
  - 従来だとチェックリストで手でやっていたことをシステムで自動化できることを理解できる

“事故前提” – DRにおける想定外への対処

近年の災害が突きつける現実
- 想定外の自然災害が起きる
- ただお金をどんどんかけられるわけではない
- 現状運用と経済性・効率性を両立する必要がある
Well-Archtectedには信頼性の柱もある
- 障害から自動的に復旧したり復旧手順をテストしたりすることが求められている
- 大事なことは何をどこまでやりたいのか
- それに合わせて原則に合わせたアプローチが必要
想定されるコストの可視化と対策の効率化
- 30 の目的別クラウド構成と料金試算例(CDP)というものがある
- 典型的なパターン(VDI/DR/コンタクトセンターなど)といくらぐらいになるかを提示している
- バックアップを使ったBCPの対策は$20くらい、などの説明がある
大阪リージョンの活用によるマルチリージョンDR戦略
- もともと国外も踏まえたDRなどを検討していたところを大阪ローカルリージョンを活用することも可能
- ただ複雑になると習熟度が必要になる
災害対策の事例
- フランスの鉄道などの会社
- AWSを利用して73%のコスト削減
- CloudEndure Disaster Recoveryを活用している
  - Oracle、MySQL、SQL Server などの保護が可能
より経営資源の選択と集中ができる